As is known, and referring now to FIG. 1, a rights management (RM) and enforcement system is highly desirable in connection with digital content 12 such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content 12 is to be distributed to users. Upon being received by the user, such user renders or ‘plays’ the digital content with the aid of an appropriate rendering device such as a media player on a personal computer 14, a portable playback device or the like.
Typically, a content owner distributing such digital content 12 wishes to restrict what the user can do with such distributed digital content 12. For example, the content owner may wish to restrict the user from copying and re-distributing such content 12 to a second user, or may wish to allow distributed digital content 12 to be played only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of media player, only by a certain type of user, etc.
However, after distribution has occurred, such content owner has very little if any control over the digital content 12. An RM system 10, then, allows the controlled rendering or playing of arbitrary forms of digital content 12, where such control is flexible and definable by the content owner of such digital content. Typically, content 12 is distributed to the user in the form of a package 13 by way of any appropriate distribution channel. The digital content package 13 as distributed may include the digital content 12 encrypted with a symmetric encryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as other information identifying the content, how to acquire a license for such content, etc.
The trust-based RM system 10 allows an owner of digital content 12 to specify rules that must be satisfied before such digital content 12 is allowed to be rendered. Such rules can include the aforementioned requirements and/or others, and may be embodied within a digital license 16 that the user/user's computing device 14 (hereinafter, such terms are interchangeable unless circumstances require otherwise) must obtain from the content owner or an agent thereof, or such rules may already be attached to the content 12. Such license 16 may for example include the decryption key (KD) for decrypting the digital content 12, perhaps encrypted according to another key decryptable by the user's computing device or other playback device.
The content owner for a piece of digital content 12 would prefer not to distribute the content 12 to the user unless such owner can trust that the user will abide by the rules specified by such content owner in the license 16 or elsewhere. Preferably, then, the user's computing device 14 or other playback device is provided with a trusted component or mechanism 18 that will not render the digital content 12 except according to such rules.
The trusted component 18 typically has an evaluator 20 that reviews the rules, and determines based on the reviewed rules whether the requesting user has the right to render the requested digital content 12 in the manner sought, among other things. As should be understood, the evaluator 20 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules, and the user should not be able to easily alter such trusted component 18 and/or the evaluator 20 for any purpose, nefarious or otherwise.
As should be understood, the rules for rendering the content 12 can specify whether the user has rights to so render based on any of several factors, including who the user is, where the user is located, what type of computing device 14 or other playback device the user is using, what rendering application is calling the RM system 10, the date, the time, etc. In addition, the rules may limit rendering to a pre-determined number of plays, or pre-determined play time, for example.
The rules may be specified according to any appropriate language and syntax. For example, the language may simply specify attributes and values that must be satisfied (DATE must be later than X, e.g.), or may require the performance of functions according to a specified script (IF DATE greater than X, THEN DO . . . , e.g.).
Upon the evaluator 20 determining that the user satisfies the rules, the digital content 12 can then be rendered. In particular, to render the content 12, the decryption key (KD) is obtained from a pre-defined source and is applied to (KD(CONTENT)) from the content package 13 to result in the actual content 12, and the actual content 12 is then in fact rendered.
In an RM system 10, content 12 is packaged by a content owner or distributor for use by a user by encrypting such content 12 and associating a set of rules with the content 12, whereby the content 12 can be rendered only in accordance with the rules. Because the content 12 can only be rendered in accordance with the rules, then, the content 12 may be freely distributed. Significantly, the content 12, the rules, and an encrypted version of the decryption key (KD) must be communicated to the computing device 14 or other playback device. Moreover, in preparing at least the encrypted version of the decryption key (KD), it is useful to tie the decryption key (KD) and by extension the license 16 containing such decryption key (KD) to the computing device 14 in such a manner that the encrypted decryption key (KD) cannot be accessed to decrypt and render the content 12 except by such computing device. Thus, the content 12, the rules, and the encrypted version of the decryption key (KD) cannot be redistributed in a manner so that the content 12 can be rendered widely and in contravention to the wishes of the content owner.
As may be appreciated, and as seen in FIG. 1, the encrypted decryption key (KD) and by extension the license 16 containing such decryption key (KD) are in fact tied to the computing device 14 by such decryption key (KD) being encrypted according to a public key (PU-C) of the computing device 14 to result in (PU-C(KD)). Presumptively, only the computing device 14 is in possession of the private key (PR-C) corresponding to (PU-C), and accordingly only such computing device 14 can apply (PR-C) to (PU-C(KD)) to reveal (KD).
In at least some instances, the computing device 14 may transfer a piece of content 12 to another device such as a portable device 62 (FIG. 3). In the course of such transfer, the computing device 14 may also construct a sub-license 16s based on the license 16 and transfer such sub-license 16s to the portable device 62 to allow the portable device 16s to render the content 16. One possible method for doing so is set forth in U.S. patent application Ser. No. 09/892,371, filed Jun. 27, 2001, hereby incorporated by reference in its entirety. As may be appreciated, however, the computing device 14 may construct the sub-license 16s based on the license 16 and transfer such sub-license 16s to the portable device 16s only if the rules set forth within the license 16 so allow.
Previously, such a portable device 62 was considered to be relatively simple, and therefore did not include much in the way of capabilities. For example, the portable device 62 did not have much memory or processing power and therefore was considered to be limited in the functions such portable device 62 could perform. As a result, the portable device 62 was not expected to perform higher level functions such as asymmetric cryptography, and was not provided with any unique indicia such as a digital device certificate with an asymmetrically validated digital signature.
However, such a portable device 62 is now no longer considered to be relatively simple, and instead has more capabilities. For example, at least some portable devices 62 now have much more memory and processing power and therefore are considered to be more capable of performing complex functions. As a result, the portable device 62 can now be expected to perform higher level functions such as asymmetric cryptography, and may now be provided with a unique indicia such as a digital device certificate with an asymmetrically validated digital signature.
Of particular interest, with such a device certificate, the portable device 62 now can be described within such a certificate in much greater detail. Thus, in the course of the computing device 14 constructing the sub-license 16s based on the license 16 and transferring such sub-license 16s to the portable device 16s only if the rules set forth within the license 16 so allow, such computing device 14 may employ such description within the device certificate to determine whether to in fact construct and transfer (i.e., issue) the aforementioned sub-license 16s. 
Accordingly, a need exists for a method and mechanism that the computing device 14 may employ in the connection with the device certificate of a portable device 62 to determine whether to issue a sub-license 16s to the portable device 62 to allow same to render a corresponding piece of digital content 16.